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MEDICATION MANAGEMENT SYSTEM 

CROSS REFERENCE TO RELATED APPLICATIONS 

This application claims priority based upon United States 
5 Provisional Application Serial No. 60/509,404 filed October 7, 
2003 and United States Provisional Application Serial No. 
60/527,583 filed December 5, 2003, which are expressly 
incorporated herein by reference in their entirety. 

10 BACKGROUND OF THE INVENTION 

The present invention relates to the field of delivering 
medication to patients, more particularly to an integrated system 
for maximizing patient safety and caregiver productivity for 
medication delivery. 

15 Modern medical care often involves the use of medical pump 

devices to deliver fluids and/or fluid medicine to patients. 
Medical pumps permit the controlled delivery of fluids to a patient, 
and such pumps have largely replaced gravity flow systems, 
primarily due to the pump' s much greater accuracy in delivery rates 

20 and dosages, and due to the possibility for flexible yet controlled 
delivery schedules. However, modern medical devices, including 
medical pumps, can be complicated and time-consuming for 
caregivers to program. Medical facilities struggle to provide 
appropriate caregiver staffing levels and training while holding 

25 down the cost of medical care. Human errors in pump programming 
and other medication errors can have adverse or even deadly 
consequences for the patient. 

Therefore, a principal object of this invention is to provide 
an integrated medication management system that reduces the risks 

30 of medication error and improves patient safety. 

A further object of the invention is to provide a medication 
management system that improves caregiver productivity. 



Attorney Docket No. 7135US03 



Another object of the invention is to provide a medication 
management system that improves the accuracy of the medication 
delivery process by eliminating labor-intensive tasks that can 
lead to human errors. 
5 A still further object of the invention is to provide a 

medication management system that relies on an 

electronically-transmitted medication order and machine readable 
indicia on the drug container, patient, and medication delivery 
device to insure the "five rights" of medication management, i.e., 

10 that the right medication is delivered to the right patient through 
the right route in the right dosage at the right time. 

Another object of the invention is to provide the caregiver 
with a pass code or machine-readable indicia to insure that only 
an authorized individual caregiver can initiate a medication order 

15 and that an authorized caregiver must confirm the medication order 
prior to its administration to the patient. 

A still further object of the invention is to provide a 
medication management system wherein the medical device receives 
delivery information electronically only through a medication 
20 management unit. 

Another object of the invention is to provide medication 
management system wherein the medical device is preprogrammed and 
executes the medication order only after a user has validated 
delivery data. 

25 A still further object of the invention is to provide a 

medication management system wherein the physical location of a 
medical device can be determined and pinpointed based on the last 
access node used by the medical device. 

Another object of the invention is to provide a medication 
30 management system for adjusting a patient-specific rule set based 
on new patient conditions and/or recent lab results. 
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A still further object of the invention is to provide a 
medication management system for determining drug-drug 
incompatibility between two medication orders for concurrent 
delivery (to the same patient at the same time) and/or in an 
5 unacceptably close time sequence. 

Another object of the invention is to provide a medication 
management system for remotely sending an order or information to 
the medical device to modulate a planned or ongoing medication 
order and delivery thereof to the patient. 
10 A still further object of the invention is to provide a 

medication management system for automatically associating a 
medical device with a patient based on wireless transmission of 
a patient ID to the medical device, thereby establishing a patient 
area network. 

15 Another object of the invention is to provide a medication 

management system for caching an updated drug library at the 
medical device to replace an existing drug library, during 
execution of a medication order. 

A still further object of the invention is to provide a 

20 medication management system for displaying a picture of the 

patient on a device within the system, such as at the medical device, 
for a caregiver to perform a visual validation of the right patient. 

Another object of the invention is to provide a medication 
management system for evaluating the performance of multiple 

25 medical devices based on information from the multiple medical 
devices. 

A still further object of the invention is to provide a 
medication management system for evaluating the performance of one 
or more caregivers based on information from multiple medical 
30 devices. 
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Another object of the invention is to provide a medication 
management system for adjusting medical device output conveyed to 
a caregiver based on multiple factors. 

These and other objects will be apparent to those skilled in 
5 the art. 
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SUMMARY OF THE INVENTION 

A medication management system includes a medication 
management unit (MMU) associated with a medical device for 
5 performing a prescribed medication order. The MMU compares 

medication order information from a first input means to machine 
readable delivery information from a second input means and 
downloads a medication order to the medical device only if the 
information from the first input means matches the information from 

10 the second input means. The medical device receives medication 
order information electronically only through the medication 
management unit (i.e., does not receive delivery information 
directly from the second input means) . The MMU permits the medical 
device to perform the order only after a user has validated delivery 

15 data at the medical device. 

The MMU determines the general physical location of a medical 
device based on the last access node used by the wireless 
connectivity capability in the medical device and an audible alarm 
can be activated to allow a user to pinpoint the physical location 

20 of the medical device more precisely. 

Using expert clinical support decision rules, the MMU also 
determines drug-drug incompatibility between two medication 
orders for concurrent delivery (to the same patient at the same 
time) and/or in an unacceptably close time sequence through the 

25 same output IV line. Further, the MMU also adjusts 

patient-specific rule sets based on newly measured or observed 
patient conditions and/or recent lab results. Advantageously, 
warnings, alarms or alerts based on violations of these rules are 
provided as close as possible to the actual delivery time so that 

30 they are more meaningful, ripe for corrective action, and less 
likely to be ignored due to incomplete information. 

Based on laboratory data or other newly received patient 
information, the MMU can modulate the medication order planned or 



Attorney Docket No. 7135US03 



currently being delivered. The MMU sends an order from the MMU 
to the medical device to modulate performance of the medication 
order. The patient and the medical device automatically associate 
with each other to form a patient area network based on wireless 
5 transmission of ID information. During execution of a medication 
order, the medical device caches an updated drug library in a cache 
memory and, upon occurrence of a triggering event, replaces an 
existing drug library in the primary memory of the device with the 
updated library. A picture of the patient is displayed at a device 

10 within the system, such as the medical device, for a caregiver to 
perform a visual validation of the right patient. The MMU evaluates 
the performance of multiple medical devices and one or more 
caregivers based on information communicated from the medical 
devices. The MMU adjusts medical device output conveyed to a 

15 caregiver based on multiple factors. 

DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a schematic diagram of the medication management 
system including a medication management unit and a medical device, 
20 integrated with an information system, according to the present 
invention; 

FIG. 1A is an alternative schematic diagram of the medication 
management system including a medication management unit and a 
medical device, integrated with an information system, according 
25 to the present invention; 

FIG. 2 is a schematic diagram of the medication management 
unit according to the invention; 

FIG. 3 is a schematic diagram illustrating some of the major 
functions performed by the medication management unit according 
30 to the invention; 

FIG. 4 is a pictorial schematic diagram of the medication 
management system and its interaction with medical devices and an 
information system in a hospital environment; 
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FIG . 4A is a schematic diagram of the medical device according 
to the invention; 

FIG. 5 is a partial flow chart of the medication management 
system processing a drug order through the medication management 
5 unit and medical device, and integrated with an information system 
according to the invention; 

FIG. 5A is a continuation of the flow chart of FIG. 5; 

FIG. 6, is an alternative flow chart of the medication 
management system processing a drug order through the medication 
10 management unit and medical device, and integrated with an 
information system according to the invention; 
FIG. 6A is a continuation of the flow chart of FIG. 6; 

FIG. 7 is a screen shot of a delivery information input device 
for entry of a caregiver specific pass code; 
15 FIG. 8 is a screen shot of a delivery information input device 

for pulling up a scan patient option; 

FIG. 9 is a screen shot of a delivery information input device 
for entry of patient-specific information; 

FIG. 10 is a screen shot of a delivery information input device 
20 displaying a task list; 

FIG. 11 is a screen shot of a delivery information input device 
displaying a medication order prescribed for a patient; 

FIG. 12 is a front view of a medical device displaying a start 
25 up screen; 

FIG. 13 is a front view of a medical device with a display 
and user interface means for selecting a clinical care area of a 
medical facility; 

FIG. 14 is a front view of a medical device with a display 
30 and user interface means for selecting a desired input channel of 
the medical device; 
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FIG. 15 is a front view of a medical device with a display 
and user interface means for confirming correct delivery 
programming code data at the medical device; 

FIG. 16 is a screen shot of a delivery information input device 
5 for confirming correct delivery programming code data; 

FIG. 17 is a schematic diagram of the medication management 
system including a medication management unit and one or more 
medical devices, showing the medication management unit 
communicates with a medical device to locate the device; 
10 FIG. 18 is a flow chart of the medication management system 

locating a medical device; 

FIG. 19 is a flow chart of the medical device 
retrieving/receiving an updated drug library from the medication 
management unit ; 

15 FIG. 20 is a flow chart of the medication management system 

updating a delivery program code executed on the medical device 
based on new information from a lab system, HIS and/or monitoring 
device; 

FIG. 21 is an alternative pictorial schematic diagram of the 
20 medication management system and its interaction with medical 
devices and the information system; and 

FIG. 22 is a flow chart of the medication management system 
generating an operation evaluation report of a caregiver or medical 
device . 

25 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

With reference to FIGS. 1 and 1A, the medication management 
system (MMS) 10 of the present invention includes a medication 
management unit (MMU) 12 and a medical device 14, typically 
30 operating in conjunction with one or more information systems or 
components of a hospital environment 16. The term hospital 
environment should be construed broadly herein to mean any medical 
care facility, including but not limited to a hospital, treatment 

8 



Attorney Docket No. 7135US03 



center, clinic, doctor's office, day surgery center, hospice, 
nursing home, and any of the above associated with a home care 
environment. As discussed below, there can be a variety of 
information systems in a hospital environment. As shown in FIG. 
5 1, the MMU 12 communicates to a hospital information system (HIS) 
18 via a caching mechanism 20 that is part of the hospital 
environment 16. 

It will be understood by those of skill in art that the caching 
mechanism 20 is primarily a pass through device for facilitating 

10 communication with the HIS 18 and its functions can be eliminated 
or incorporated into the MMU 12 (FIG. 1A) and/or the medical device 
14 and/or the HIS 18 and/or other information systems or components 
within the hospital environment 16. The Caching Mechanism 20 
provides temporary storage of hospital information data separate 

15 from the HIS 18, the medication administration record system (MAR) 
22, pharmacy information system (PhlS) 24, physician order entry 
(POE) 26, and/or Lab System 28. The Caching Mechanism 20 provides 
information storage accessible to the Medication Management System 
10 to support scenarios where direct access to data within the 

20 hospital environment 16 is not available or not desired. For 
example, the caching mechanism 20 provides continued flow of 
information in and out of the MMU 12 in instances where the HIS 
18 down or the connectivity between the MMU 12 and the electronic 
network (not shown) is down. The caching mechanism 20 also provides 

25 improved response time to queries from the MMU 12 to the HIS 18, 
as direct queries to the HIS 18 are not consistently processed at 
the same speed and often require a longer period of time for the 
HIS 18 to process. 

The HIS 18 communicates with a medication administration 

30 record system (MAR) 22 for maintaining medication records and a 
pharmacy information system (PhlS) 24 for delivering drug orders 
to the HIS. A physician/provider order entry (POE) device 26 
permits a healthcare provider to deliver a medication order 
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prescribed for a patient to the hospital information system 
directly or indirectly via the PhlS 24. One skilled in the art 
will also appreciate that a medication order can be sent to the 
MMU 12 directly from the PhlS 24 or POE device 26. As used herein 
5 the term medication order is defined as an order to administer 
something that has a physiological impact on a person or animal , 
including but not limited to liquid or gaseous fluids, drugs or 
medicines, liquid nutritional products and combinations thereof. 
Lab system 28 and monitoring device 30 also communicate with 

10 the MMU 12 to deliver updated patient-specific information to the 
MMU 12. For example, the lab system 28 sends lab results of blood 
work on a specific patient to the MMU 12, while the monitoring 
device 30 sends current and/or logged monitoring information such 
as heart rate to the MMU 12. As shown, the MMU 12 communicates 

15 directly to the lab system 28 and monitoring device 30. However, 
it will be understood to those of skill in art that the MMU 12 can 
communicate to the lab system 28 and monitoring device 30 
indirectly via the HIS 18, the caching mechanism 20, the medical 
device 14 or some other intermediary device or system. This 

20 real-time or near delivery time patient-specific information is 
useful in adapting patient therapy because it may not have been 
available at the time the medication order was prescribed. As used 
herein, the term real-time denotes a response time with a latency 
of less than 3 seconds. The real-time digital communications 

25 between the MMU 12 and other interconnected devices and networks 
prevents errors in patient care before administration of 
medications to the patient, especially in the critical seconds just 
prior to the start of medication delivery. 

Delivery information input device 32 also communicates with 

30 the MMU 12 to assist in processing drug orders for delivery through 
the MMU 12. The delivery information input device 32 can be any 
sort of data input means, including those adapted to read machine 
readable indicia such as barcode labels; for example a personal 

10 
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digital assistant (PDA) with a barcode scanner. Hereinafter the 
delivery information input device 32 will be referred to as input 
device 32. Alternatively, the machine readable indicia may be in 
other known forms, such as radio frequency identification (RFID) 
tag, two-dimensional bar code, ID matrix, transmitted radio ID code, 
human biometric data such as fingerprints, etc. and the input 
device 32 adapted to "read" or recognize such indicia. The input 
device 32 is shown as a separate device from the medical device 
14; alternatively, the input device 32 communicates directly with 
the medical device 14 or may be integrated wholly or in part with 
the medical device. 

With reference to FIG . 2, the medication management unit 12 
includes a network interface 34 for connecting the MMU 12 to 
multiple components of a hospital environment 16, the medical 
device 14, and any other desired device or network. A processing 
unit 36 is included in MMU 12 and performs various operations 
described in greater detail below. A display/input device 38 
communicates with the processing unit 36 and allows the user to 
receive output from processing unit 36 and/or input information 
into the processing unit 36. Those of ordinary skill in the- art 
will appreciate that display/input device 38 may be provided as 
a separate display device and a separate input device. 

An electronic storage medium 40 communicates with the 
processing unit 36 and stores programming code and data necessary 
for the processing unit 36 to perform the functions of the MMU 12. 
More specifically, the storage medium 40 stores multiple programs 
formed in accordance with the present invention for various 
functions of the MMU 12 including but not limited to the following 
programs: Maintain Drug Library 42; Download Drug Library 44; 
Process Drug Order 46; Maintain Expert Clinical Rules 48; Apply 
Expert Clinical Rules 50; Monitor Pumps 52; Monitor Lines 54; 
Generate Reports 56; View Data 58; Configure the MMS 60; and Monitor 
the MMS 62. The Maintain Drug Library 42 program creates, updates, 

11 



Attorney Docket No. 7135US03 



and deletes drug entries and establishes a current active drug 
library. The Download Drug Library 44 program updates medical 
devices 14 with the current drug library. The Process Drug Order 
46 program processes the medication order for a patient, verifying 
5 that the point of care (POC) medication and delivery parameters 
match those ordered. The Maintain Expert Clinical Rules 48 program 
creates, updates, and deletes the rules that describe the 
hospital's therapy and protocol regimens. The Apply Expert 
Clinical Rules 50 program performs logic processing to ensure 

10 safety and considers other infusions or medication orders, patient 
demographics, and current patient conditions that include blood 
chemistry values such as insulin/glucose, monitored data such as 
pulse and respiration, and clinician assessments such as pain or 
responsiveness. The Monitor Pumps 52 program acquires ongoing 

15 updates of status, events, and alarms transmitted both real-time 
and in batch mode, as well as tracking the location, current 
assignment, and software versions such as the drug library version 
residing on medical device 14. The Monitor Lines 54 program 
acquires ongoing updates of status, events and alarms for each 

20 channel or line for a medical device 14 that supports multiple drug 
delivery channels or lines. The Generate Reports 56 program 
provides a mechanism that allows the user to generate various 
reports of the data held in the MMU storage medium 40. The View 
Data 58 program provides a mechanism that supports various display 

25 or view capabilities for users of the MMU 12. The Notifications 
59 program provides a mechanism for scheduling and delivery of 
events to external systems and users. The Configure the MMS 60 
program provides a mechanism for system administrators to install 
and configure the MMS 10. The Monitor the MMS 62 program enables 

30 information technology operations staff capabilities to see the 
current status of MMS 10 components and processing, and other 
aspects of day-to-day operations such as system start up, shut 
down, backup and restore. 

12 
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With reference to FIG. 3, the various functional programs 
42-62 of the MMU 12, each including separate features and rules, 
are partitioned (at a higher level than shown in FIG . 2) and 
logically organized into interrelated managing units of the MMU 
5 12. As shown, the MMU 12 includes an asset manager 64, an alarm 
manager 66, a drug library manager (such as, for example, ABBOTT 
MEDNET™) 68, a caregiver manager 70, a therapy manager 72, and/or 
a clinical data manager 73. However, one of ordinary skill in the 
art will appreciate that additional or alternative hospital system 

10 managing units can be provided without departing from the present 
invention. Additionally, the MMU 12 includes a master adjudicator 
74 between the separate interrelated hospital system managing 
units 64-73 of the MMU 12, to regulate the interaction between the 
separate management units. 

15 Further, while the MMU 12 as described herein appears as a 

single device, there may be more than one MMU 12 operating 
harmoniously and sharing the same database. For example the MMU 
12 can consist of a collection of MMU specific applications running 
on distinct servers in order to avoid a single point of failure, 

20 address availability requirements, and handle a high volume of 
requests. In this example, each individual server portion of the 
MMU 12 operates in conjunction with other server portions of the 
MMU 12 to redirect service requests to another server portion of 
the MMU 12. Additionally, the master adjudicator 74 assigns 

25 redirected service requests to another server portion of the MMU 
12, prioritizing each request and also ensuring that each request 
is processed. 

With reference to FIGS. 2 and 3, the managing units 64-72 each 
include separate features and rules to govern their operation. For 
30 example the asset manager 64 governs the execution of the Monitor 
Pumps 52 and Monitor Lines 54 programs; the drug library manager 
68 governs the execution of the Drug Library 42 and Download Drug 

13 
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Library 4 4 programs; the therapy manager 72 governs the execution 
of the Process Drug Order 4 6, Maintain Expert Clinical Rules 48, 
and Apply Expert Clinical Rules 50 programs; and the clinical data 
manager 73 governs the execution of the Generate Reports 56 and 
5 View Data 58 programs. Other distribution of the functional MMU 
programs 42-62 among the hospital system managing units 64-73 can 
be made in accordance with the present invention. 

With reference to FIG. 4, an electronic network 76 connects 
the MMU 12, medical device 14, HIS 18, and input device 32 for 

10 electronic communication. The electronic network 76 can be a 

completely wireless network, a completely hard wired network, or 
some combination thereof. The medical device 14 and input device 
32 are located in a treatment location 77. As shown, the medical 
device 14 and input device 32 are equipped with antennas 78 and 

15 80, respectively. The antennae 78 and 80 provide for wireless 
communication to the electronic network 76 via an antenna 82 of 
access node 84 connected to the electronic network 76. Further 
details on the antenna 78 can be found in commonly assigned 
co-pending application entitled SYSTEM FOR MAINTAINING DRUG - 

20 INFORMATION AND COMMUNICATING WITH MEDICATION DELIVERY DEVICES 
filed on February 20, 2004, which is expressly incorporated herein 
in its entirety. 

In the context of the present invention, the term "medical 
device" includes without limitation a device that acts upon a 

25 cassette, reservoir, vial, syringe, or tubing to convey medication 
or fluid to or from a patient (for example, an enteral pump, 
infusion pump, a patient controlled analgesia (PCA) or pain 
management medication pump, or a suction pump) , a monitor for 
monitoring patient vital signs or other parameters, or a diagnostic 

30 device. 

For the purpose of exemplary illustration only, the medical 
device 14 of FIG. 4 is disclosed as a cassette type infusion pump. 
The pump style medical device 14 includes a user interface means 
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86, display 88, first channel 90, and first channel machine 
readable indicator 92. A first IV line 98 has a conventional 
cassette 99A (not shown) that is inserted into the first channel 
90, and includes a medication bag 100 with a machine readable 
5 indicator 102. A second IV line 101 is connected to an input port 
of the cassette 99A, and includes a medication bag 106 with a 
machine readable indicator 108. A single output IV line 98 is 
connected to an outlet port of the cassette 99A and connected to 
a patient 110 who has a machine readable indicator 112 on a 

10 wristband, ankle band, badge or similar article that includes 

patient-specific and or identifying information, including but not 
limited to patient ID, and demographics. 

In an alternative embodiment illustrated by dashed lines in 
FIG. 4, the medical device 14 is a multi-channel pump having a first 

15 channel 90 with first channel machine readable indicator 92 and 
at least a second channel 94 with a second channel machine readable 
indicator 96. The line 101 from the medication bag 106 is 
eliminated and replaced by line 104 with a cassette 99B (not shown) 
inserted into the second channel 94 and an output line 104 extends 

20 from the cassette to the patient. The same type of cassette 99 
(not shown) is inserted in the first channel 90. Additional details 
on such a multi-channel pump and cassette 99A can be found in 
commonly owned United States Patent Application Serial No. 
10/696,830 entitled MEDICAL DEVICE SYSTEM, which is incorporated 

25 by reference herein in its entirety. 

Within a patient area network 113 (hereinafter, PAN 113) , a 
caregiver 114 (if present) has a machine readable indicator 116 
on a wristband, badge, or similar article and operates the input 
device 32. The input device 32 includes an input means 118 for 

30 reading the machine readable indicators 92, 96, 102, 108, 112, and 
116. An input/output device 120 is included on the input device 
32. The input/output device 120 allows the user to receive output 
from the input device 32 and/or input into the input device 32. 

15 
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Those of ordinary skill in the art will appreciate that 
display/input device 120 may be provided as a separate display 
device and a separate input device. 

With reference to FIG. 4A, the pump style medical device 14 
5 includes a network interface 122 for connecting the medical device 
14 to the electronic network 7 6. The network interface 122 operates 
the antenna 78 for wireless connection to the electronic network 
76. A processor 124 is included in the medical device 14 and 
performs various operations described in greater detail below. The 

10 input/output device 87 (display 88 and user interface means 86) 
allows the user to receive output from the medical device 14 and/or 
input information into the medical device 14. Those of ordinary 
skill in the art will appreciate that input/output device 87 may 
be provided as a separate display device and a separate input device 

15 (as shown in FIG. 4, display 88 and user interface means 86) or 
combined into a touch screen for both input and output. A memory 
126 communicates with the processor 124 and stores code and data 
necessary for the processor 124 to perform the functions of the 
medical device 14. More specifically, the memory 126 stores 

20 multiple programs formed in accordance with the present invention 
for various functions of the medical device 14 as is relates to 
the MMU 12 including the following programs: Process Drug Order 
128 , Monitor Pump 130 , and Download Drug Library 132. 

With reference to FIGS. 5 and 5A, the functional steps of the 

25 Process Drug Order 4 6 and Apply Expert Clinical Rules 50 programs 
of the MMU 12 and the Process Drug Order 128 program of the medical 
device 14 are shown in operation with the HIS 18 , the caching 
mechanism 20 and the input device 32. 

With reference to FIGS. 4, 5 and 7, to begin to process a drug 

30 order, the input device 32 displays a default screen (not shown) 
on input /output device 120 which the caregiver uses to access 
password screen 133B (FIG. 7) . The password screen 133B prompts 
the caregiver 114 to enter caregiver specific identification 
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information (caregiver ID) . The caregiver 114 enters caregiver 
ID such as a username and/or password or pass code, or the machine 
readable indicator 116. The input device 32 enters this caregiver 
ID at step 134. 

5 With reference to FIGS. 4, 5 and 8-9, the input device 32 then 

displays a scan patient screen 135A (FIG. 8) which prompts the 
caregiver 114 to enter patient-specific identification 
information (patient ID) . The caregiver 114 enters the patient 
ID such as the machine readable indicator 112. The input device 

10 32 enters this patient ID and at step 136, and displays a confirmed 
scan patient screen 135B (FIG. 9) indicating that the patient ID 
was successfully entered into the input device 32. 

With reference to FIG. 5, the input device 32 then transmits 
the patient ID to the caching mechanism 20 at step 138. The caching 

15 mechanism 20 transmits the patient ID to the HIS 18 at step 140. 
The HIS 18 .retrieves a patient-specific task list and 
patient-specific order information based on the patient ID and 
transmits both to the caching mechanism 20 at step 142. The order 
information includes but is not limited to an order detail for a 

20 medication order, patient demographic information, and other 

hospital information systems data such as lab results data. The 
caching mechanism 20 transmits the task list to the input device 
32 at step 143. 

With reference to FIGS. 4, 5 and 10-11, the input device 32 
25 then displays a task list screen 143A (FIG. 10) which prompts the 
caregiver 114 to accesses the task list on the input device 32. 
The input device 32 prompts the caregiver 114 to enter drug specific 
identification information (dispense ID) . The caregiver 114 
enters a dispense ID such as the drug container specific machine 
30 readable indicator 102. The input device 32 enters this dispense 
ID at step 144. The input device 32 processes the dispense ID to 
select the correct task from the task list, then displays a task 
screen 143B (FIG. 11), and transmits a dispense ID to the caching 

17 
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mechanism 20 requesting an order ID at step 146. The caching 
mechanism 20 transmits a dispense ID to the HIS 18 requesting an 
order ID at step 148 . The HIS 18 transmits an order ID to the caching 
mechanism 20 at step 150. The caching mechanism 20 forwards this 
5 order ID to the input device 32 at step 152. 

Alternatively, the three entered IDs (patient ID, dispense 
ID, and channel ID) are entered in a different specific order or 
without regard to order. Where the IDs are entered without regard 
to order, the IDs would be maintained within the MMS 10 and/or 

10 caching mechanism 20 as they are entered, so that the IDs can be 
recalled when needed to complete the medication delivery workflow. 

The input device 32 matches the order ID with an item in the 
task list to ensure a Five Rights check at step 154. The "Five 
Rights" in this section refer to the "Five Rights of Medical 

15 Administration". Alternatively, the Five Rights check is done at 
the MMU 12 once the MMU 12 receives the order information as well 
as the patient, dispense, and channel IDs. A description of these 
"rights" follows. Right patient, is the drug being administered 
to the correct patient. Right drug, is the correct drug being 

20 administered to the patient. Right dose, is the correct dosage 
of the drug being administered to the patient. Right time, is the 
drug being administered to the patient at the correct time. Right 
route, is the drug being administered into the patient by the 
correct route, in this case intravenously through an IV. Once the 

25 order ID and item in the task list are reconciled, the input device 
32 sends an order confirmed message to the caching mechanism 20 
at step 156. In response, the caching mechanism 20 sends the order 
detail (medication order prescribed for a patient) of the order 
information to the input device 32 at step 158. 

30 With reference to FIGS. 4, 5, 11, the input device 32 then 

displays a scan device/channel screen 143B (FIG. 11) which prompts 
the caregiver 114 to enter channel identification information 
(channel ID) regarding which channels of the medical device 14 are 
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to be used for the delivery. The caregiver 114 enters a channel 
ID such as the machine readable indicator 92. The input device 
32 enters this channel ID at step 160, and displays a confirmed 
scan device screen 159B (FIG. 11B) indicating that the channel ID 
5 was successfully entered into the input device 32. It will be 
appreciated that the channel ID indicator 92 can include 
information also identifying the medical device 14 (medical device 
ID) . Alternatively, it is contemplated that an additional machine 
readable indicator (not shown) may be provided for the medical 

10 device itself separate from the channel ID machine readable 

indicator 92. If the medical device 14 has a single channel, a 
single indicator will clearly suffice. If the medical device 14 
is a multi-channel device, the channel indicators can also carry 
information that uniquely identifies the device the channel is on. 

15 At any rate, it should be apparent that a second entry of a combined 
device/channel ID may be redundant and could be eliminated. The 
input device 32 then transmits the delivery information including 
caregiver ID, patient ID, medical device ID and/or channel ID, 
dispense ID, and order ID to the MMU 12 at step 162. 

20 With reference to FIGS. 4, 5 and 12-14, when the medical device 

14 is turned on at step 164 the medical device 14 displays a start 
up screen 163A (FIG. 12) on the display 88 of the medical device 
14. The medical device 14 then displays a clinical care area 
selection screen 163B (FIG. 13) which prompts the caregiver 114 

25 to select the clinical care area (CCA) that the medical device 14 
is being assigned to. The caregiver 114 enters or selects the CCA 
at step 166 using scroll and select/enter keys on the user interface 
means 86. The medical device 14 then displays a channel selection 
screen 163C (FIG. 14) that prompts the caregiver 114 to select the 

30 desired channel (90 or 94) or bag source (100 or 106 ) using soft 
keys 163D-G, more particularly 163E, 163F respectively. The 
medical device 14 enters this channel ID at step 168. The CCA 
information is transmitted to the MMU 12 by the medical device 14 
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at step 170. Alternatively, where the CCA is known and available 
to the HIS 18, the CCA can be automatically generated for the 
medical device 14, and sent from the HIS 18 to the MMU 12 

With reference to FIGS. 2 and 5, the MMU 12 executes the 
5 Process Drug Order 4 6 program and sends an active order request 
based on the delivery information from the input device 32 to the 
caching mechanism 20 at step 172 . The caching mechanism 20 responds 
by sending the corresponding patient-specific order information 
to the MMU 12 at step 174. The caching mechanism 20 may send to 
10 the MMU 12 order information regarding all information associated 
with the particular patient, including but not limited to order 
detail for a medication order, patient demographic information, 
and other hospital information systems data such as lab results 
data or monitoring data. 

15 Referring to FIG. 5A, the MMU 12 then executes the Apply Expert 

Clinical Rules 50 program to process the CCA information from the 
medical device 14 and the delivery information from the input 
device 32, at step 178. The Apply Expert Clinical Rules 50 program 
compares the delivery information with an expert rule set to 

20 determines expert rule set violations based on correlating 

treatment based protocols, disease based protocols, drug-drug 
incompatibility, patient data (age, height, weight, etc) , vital 
signs, fluid in/out, blood chemistry, and status assessments (such 
as pain and cognition) . As used herein, the term drug-drug 

25 incompatibility includes but is not limited to determinations of 
drug-drug interactions and/or drug-drug compatibility between two 
or more medication orders for concurrent delivery (to the same 
patient at the same time) and/or in a time sequence for the same 
patient (i.e. through a common output IV line). In cases where 

30 the Apply Expert Clinical Rules 50 program finds an expert rule 
set violation (such as a drug-drug incompatibility) , the Apply 
Expert Clinical Rules 50 program generates an alarm and/or requires 
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a time delay in execution for one of the two separate delivery 
information submissions . 

The Apply Expert Clinical Rules 50 program also establishes 
a patient-specific rule algorithm. The patient-specific rule 
5 algorithm is primarily based on the expert rule set described above 
applied to a specific order detail. The patient-specific rule 
algorithm generates a patient-specific rule set (discussed in 
greater detail below, at the description of FIG. 20) according to 
patient-specific order information including but not limited to 

10 patient demographic information, and other hospital information 
systems data such as lab results data or monitoring data. The 
patient-specific rule set includes hard and soft dosage limits for 
each drug being administered. The patient-specific rule set is 
included in the delivery programming code sent to the medical 

15 device 14 at step 182. 

Any alarms generated by the Process Drug Order 4 6 or Apply 
Expert Clinical Rules 50 programs are delivered to the medical 
device 14, HIS 18, and/or input device 32, computer 254 (FIG. 17), 
at step 180. Computer 254 can be located in a remote nurse station 

20 or a biomedical technician area. If no alarms are generated,, the 
MMU 12 transmits a delivery program code to the medical device 14, 
at step 182. The delivery program code sent from MMU 12 to the 
medical device 14 includes a patient-specific rule set generated 
from any rule based adjudication at the MMU 12, including hard and 

25 soft dosage limits for each drug being administered. The medical 
device 14 caches the patient-specific rule set contained in the 
delivery programcode . Alternatively, the MMU 12 can generate an 
alarm at the medical device 14 or another location and not download 
the deliveryprogram code. 

30 With reference to FIGS. 5, 5A and 15, the medical device 14 

displays an order dose confirmation screen 187A (FIG. 15) which 
prompts the caregiver 114 to confirm the delivery data. As shown, 
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the caregiver 114 selects the "yes" soft key 187B on the medical 
device 14 to confirm the delivery data and the "no" soft key 187C 
to cancel the delivery. The caregiver 114 confirms the delivery 
data at the medical device 14 at step 188. Once the caregiver 114 
5 confirms the delivery data at the medical device 14, the medical 
device 14 then executes the delivery program code and begins 
infusion at step 198. As part of the program code, the infusion 
may be delayed for a predetermined period of time. 

Alternatively, confirmation from the caregiver can be made 

10 at the input device 32 or required from both the input device 32 
and medical device 14. As shown, a redundant additional 
confirmation performed by the caregiver 114 at the input device 
32 after the medical device has received the delivery program code. 
Specifically, the medical device 14 transmits a canonical 

15 representation of the delivery programming code data (delivery 
data) to the MMU 12 detailing the infusion to be performed by the 
medical device 14, at step 184. The MMU 12 then transmits the same 
delivery data that was originally transmitted to the medical device 
14 to the input device 32 at step 186. Alternatively, the delivery 

20 data can be passed to another remote computer (254 in FIG. 17), 
including but not limited to a computer at a nurse station, for 
confirmation . 

With reference to FIGS. 5A and 16, the input device 32 displays 
an order dose confirmation screen 191A (FIG. 16) that prompts the 

25 caregiver 114 to confirm the delivery data. As shown, the caregiver 
114 selects the complete button 191B on the input device 32 to 
confirm the delivery data and the cancel button 191C to cancel the 
delivery. The caregiver 114 confirms the delivery data at the input 
device 32 at step 192, and the confirmation is used for 

30 documentation by the HIS 18, or other systems within the hospital 
environment 16. 

With reference to FIGS. 4A and 5A, during infusion, the 
medical device 14 executes its Process Drug Order 128 program. The 
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Process Drug Order 128 program sends infusion change events and 
infusion time events in a delivery event log message 200 to the 
MMU 12. The MMU 12 forwards these delivery event log messages to 
the input device 32 or other system within the hospital environment 
5 16 at step 202. The caregiver 114 acknowledges these delivery event 
log messages on the input device 32, at step 204 . The input device 
32 then sends an acknowledged delivery event log message 206 to 
the caching mechanism 20, detailing the delivery event, the 
caregiver ID, and the caregiver acknowledgment. The caching 
10 mechanism passes the delivery event message to the HIS 18 at step 
208. 

Once infusion has ended at step 210, the medical device 14 
sends an infusion ended message 212 to the MMU 12. The MMU 12 then 
aggregates all the delivery event messages 200 sent during the 

15 infusion at step 214. The MMU 12 sends the aggregated delivery 
events 216 to the input device 32. The caregiver 114 enters a 
completed task 218 on the input device 32, and sends the aggregated 
delivery events to the caching mechanism at step 220, which in turn 
passes the delivery event log messages to the HIS 18 at step 222. 

20 With reference to FIG. 6 and 6A, an alternative flow chart 

of the MMS 10 processing a drug order through the MMU 12 and medical 
device 14 is shown. With reference to FIGS. 4, 6 and 6A, the 
caregiver 114 enters the patient ID, which then is stored in the 
caching mechanism 20. The caching mechanism 20 transmits the 

25 patient ID to the HIS 18 and retrieves a patient-specific task list 
for that patient ID. The caregiver 114 then enters the dispense 
ID, which subsequently is stored in the caching mechanism 20. The 
caching mechanism 20 transmits the dispense ID to the HIS 18, and 
retrieves a patient-specific order information, including but not 

30 limited to an order detail, patient demographic information, and 
other hospital information systems data such as lab results data. 
The caregiver 114 then enters the channel ID, which is stored in 
the MMU 12. 
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Alternatively, the three entered IDs (patient ID, dispense 
ID, and channel ID) are entered in a different specific order or 
without regard to order. Where the IDs are entered without regard 
to order, the IDs would be maintained within the MMS 10 and or 
5 caching mechanism 20 as they are entered, so that the IDs can be 
recalled when needed to complete the medication delivery workflow. 

Upon receipt of the channel ID, the MMU 12 requests the order 
information (order detail, patient demographic information, and 
other hospital information systems data) and retrieves it from the 

10 caching mechanism 20. This order information is stored within the 
MMU 12 and utilized for subsequent rule processing such as "Five 
Rights" checking and other rule set algorithms. The Process Drug 
Order 4 6 program processes the delivery information from the input 
device 32 (including caregiver ID, patient ID, medical 

15 device/channel ID, and dispense ID) and compares this delivery 
information with the corresponding order detail portion of the 
order information from the caching mechanism 20, at step 176. Where 
the order information and delivery information do not match, the 
device program code downloaded to the medical device 14 at step 

20 182 includes an alarm message indicating that the five rights check 
was not met. Additionally, the alarm message can include a 
description of which particular right (s) did not match. 
Alternatively, the NMU 12 can generate an alarm at the medical 
device 14 or another location and not download the program code 

25 for delivery of the medication order. 

Alternatively, the MMU 12 can accept a Five Rights check from 
another device, such as a HIS 18 or an input device 32. This check 
can be accepted either by a direct data element being sent to the 
MMU 12 indicating a Five Rights check, or implied through the 

30 workflow provided by the HIS 18 or input device 32. 

The other steps shown in FIGS. 6 and 6A are similar to 
corresponding steps in FIGS. 5 and 5A. Accordingly, these steps 
will not be described with any further detail here. One skilled 
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in the art will appreciate that the vertical lines in FIGS. 5, 5A, 
6, 6A do not necessarily represent a firm time sequence. Some steps 
may be done sooner than shown (for example, turning on the medical 
device) or later than shown (for example, aggregate delivery 
5 events) . 

With reference to FIGS. 2, 4A, 5, 5A and 20, in one embodiment, 
the Process Drug Order 4 6 program of the MMU 12 and the 
corresponding Process Drug Order 128 program of the medical device 
14 permit the MMU 12 to remotely control the medical device 14 to 

10 modulate performance of a medication order. For example, the MMU 
12 can remotely start and/or stop the medical device 14. Once the 
delivery program code is received by the medical device 14 at step 
184, the Process Drug Order 4 6 of MMU 12 remotely starts execution 
of the infusion by sending a start order 224, which triggers the 

15 medical device to begin infusion at step 225. Likewise, when the 
infusion is to end at step 228, the Process Drug Order 46 program 
can remotely stop the infusion by sending a stop order 226 to the 
medical device 14, which triggers the medical device to end 
infusion at step 228. In most cases, the MMU 12 requires the 

20 caregiver to confirm the start or stop of execution. This 

confirmation by the caregiver may take place at the input device 
32 or the medical device 14. However, one skilled in the art will 
appreciate that there may be emergency situations where an order 
could and should be stopped without human confirmation. 

25 With reference to FIGS. 2, 5, 5A and 20, in one embodiment, 

the Apply Expert Clinical Rules 50 program of the MMU 12 permits 
the MMU 12 to adjust a previously fixed patient-specific rule set 
based on new patient conditions and/or recent lab results, and 
notify the caregiver that adjustment is recommended by the MMU 12. 

30 As discussed above in regard to FIGS. 5 and 5A, the Apply Expert 
Clinical Rules 50 program establishes a patient-specific rule 
algorithm. The patient-specific rule algorithm is primarily based 
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on the expert rule set described above applied to a specific order 
detail. The patient-specific rule algorithm generates a 
patient-specific rule set according to patient-specific order 
information including but not limited to patient demographic 
5 information, and other hospital information systems data such as 
lab results data or monitoring data. The patient-specific rule 
set includes hard and soft dosage limits for each drug being 
administered, and these hard and soft dosage limits likewise are 
adjusted when the patient-specific rule set is adjusted. 

10 For example, during or even before an infusion, the MMU 12 

may receive updated patient information that can impact an ongoing 
or impending infusion. As shown in FIG. 20, the lab 28 sends updated 
patient-specific lab results to the MMU 12 at step 230. Likewise, 
the monitoring device 30 sends updated patient-specific monitoring 

15 information to the MMU 12 at. step 232. Additionally the MMU 12 
queries the HIS 18 for patient information including: Patient 
Allergies, Patient Diet, and Current Patient Medical Orders. 
Patient Allergies are used to check for drug-allergy interactions, 
at step 231. Patient Diet information is used to check for 

20 drug-food interactions. Current Patient Medical Orders are used 
to check for drug-drug incompatibility. Like the patient 
information gathered from the Lab 28 and the monitoring device 30, 
the patient information from HIS 18 is also used by the MMU 12 to 
update the delivery program order. 

25 As shown in FIGS. 5 and 5A, in cases where the MMU 12 is 

processing a drug order for the medical device 14, the MMU 12 
executes the Apply Expert Clinical Rules 50 program at step 178 
to establish a patient-specific rule set based on updated patient 
information received or retrieved from the lab 28, the monitoring 

30 device 30, and or the HIS 18 (FIG. 20) . This real-time or near 
delivery time updated patient-specific information is useful in 
adapting patient therapy because it may not have been available 



26 



Attorney Docket No. 7135US03 



at the time the medication order was prescribed. 

As shown in FIG. 20, The MMU 12 also modifies the existing 
patient-specific rule set in the existing delivery program code 
at step 234 based on updated patient information received or 
5 retrieved from the lab 28, the monitoring device 30, and or the 
HIS 18. The MMU 12 optionally alerts the input device 32 and/or 
the medical device 14 of changes to the patient-specific rule set. 
MMU 12 also optionally generates an alert message if the delivery 
programming code violates any parameter of the adjusted hard and 

10 soft dosage limits. Additionally, the MMU 12 optionally requests 
confirmation by the caregiver prior to instituting the new 
patient-specific rule set. The MMU 12 then delivers an updated 
delivery program code to the medical device 14 for execution at 
step 236. The medical device 14 then executes this updated delivery 

15 program code as step 238. The updated delivery program code sent 
from MMU 12 to the medical device 14 includes an updated 
patient-specific rule, set generated from any rule based 
adjudication at the MMU 12, including hard and soft dosage limits 
for each drug being administered. The medical device 14 caches 

20 the updated patient-specific rule set contained in the delivery 
program code. Additionally, the MMU 12 collects, stores, and 
reports the changes to the patient-specific rule set, changes to 
the hard and soft limits, as well as the history of each medication 
order. 

25 An example of how the MMU 12 updates the patient-specific rule 

set based on lab results or monitored patient conditions is 
provided below with respect to the drug Heparin, which is a blood 
thinner. The medication order entered by the physician might be: 

Give heparin 1000 units/hour. If the activated partial 
30 thromboplastin time (APTT) > 75 seconds then decrease 

heparin to 800 units/hour. 
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If the medical device 14 has started the infusion at 1000 units/hour 
and the MMU 12 subsequently receives an updated APTT value of 100 
seconds from the lab 28 on the patient, the MMU automatically 
commands the medical device 14 to decrease the infusion rate to 
5 800 units/hour. Alternatively, when the MMU is notified by lab 28 , 
an alarm will be generated to the PDA 32 and/or the medical device 
14 to notify the caregiver of the need to change the infusion rate. 
The MMU can preprogram the pump for the caregiver to confirm the 
recommended change . 

10 In further embodiment or method, the hospital may establish 

expert rules or clinical decision support rules in the MMU 12 that 
will be applied automatically to incoming prescribed orders, such 
that the physician may simply write an order for 1000 or 1200 
units/hour. The hospital best practices formulated by the 

15 appropriate medical personnel are established in the MMU 12 and 
can dictate that all heparin orders are to be conditioned on the 
APTT lab result and such an expert rule or clinical decision support 
rule will be used by the MMU 12 to govern the operation of the 
medical device 14 . The MMU 12 also can check the most recent patient 

20 data and provide an alarm and/or temporarily modify the delivery 
order prior to the start of the infusion if the prescribed order 
is no longer appropriate given the expert rules or clinical 
decision support rules and the latest lab results or monitored 
patient conditions. It should be apparent that this kind of 

25 intervention by the MMU 12 during or immediately prior to an 

infusion is particularly useful in preventing adverse consequences 
for the patient and the hospital. 

Where the MMU 12 adjusts a previously fixed patient-specific 
rule set based on new patient conditions and/or recent lab results, 
30 as described above, the MMU 12 provides dynamic advanced reports 
of real-time rule set changes in relation to changes in the 
condition of the patient (an "information cascade") . These 
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advanced reports detail the history of both hard and soft upper 
and lower limits, as well as the activation of overrides and 
confirmations based on these limits for each medical device 14 
managed by the MMU 12. Further details on this feature can be found 
5 in commonly owned co-pending application entitled SYSTEM FOR 

MAINTAINING DRUG INFORMATION AND COMMUNICATING WITH MEDICATION 
DELIVERY DEVICES filed on February 20, 2004, which is expressly 
incorporated herein in its entirety. 

With reference to FIGS. 2, 4A and 19, the Download Drug Library 

10 4 4 program in the MMU 12 and the corresponding Download Drug Library 
132 program in the medical device 14 operate to send a drug library 
to the medical device 14 from the MMU 12. The drug library includes 
drug and device related information, which may include but is not 
limited to drug name, drug class, drug concentration, drug amount, 

15 drug units, diluent amount, diluent units, dosing units, delivery 
dose or rate, medication parameters or limits, device/inf user 
settings and/or modes, CCA designations and constraints, and 
library version. The Download Drug Library 132 program is designed 
to cache in a cache memory 126A a new database or drug library at 

20 medical device 14 while maintaining an existing older version 

database or drug library in its primary memory 126. This allows 
the medical device to operate or deliver an infusion based on the 
older version of the drug library without disruption until a 
trigger event occurs, at which time the new drug library replaces 

25 the older version in the primary memory 126. It is contemplated 
that the medical device 14 can be equipped with an initial drug 
library at the factory. 

The Download Drug Library 132 program in the medical 
device 14 begins at a block 240 and at block 242 a determination 

30 is made that a drug library update needed event has occurred. For 
instance the drug library update needed event could be a completed 
infusion, a stopped infusion, elapsed time, a specific date and 
time, creation of the new drug library, the medical device 14 being 
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or entering into a particular configurable mode such as stop, 
"sleep" or "wakeup", connection of the medical device 14 to an 
access node 84 in a new CCA, a download of a new or modified drug 
library to the medication management unit, or a determination that 
5 the existing drug library at the medical device needs updating. 
The configurable mode could be any number of device modes including 
a power-on sleeping mode and a power-off mode. The determination 
that a drug library update needed event has occurred can be made 
by (at) the MMU 12, the medical device 14 or by a combination of 
10 the two. 

Based on the specific drug library update needed event, the 
Download Drug Library 132 proceeds to block 244 where it retrieves 
or receives a new drug library. Once retrieved or received, the 
Download Drug Library 132 proceeds to block 24 6 where it stores 

15 the new drug library in the cache memory 12 6A of the medical device 
14. While a medical device 14 is operating on a patient or in an 
otherwise nonconf igurable mode, information such as a new drug 
library or database is stored in a cache memory 126A of the medical 
device 14 as the information is received from a wired or wireless 

20 link through the network interface 122. The Download Drug Library 
132 proceeds to block 248 where it determines if a specific trigger 
event has occurred. For instance, the trigger event could be a 
completed infusion, a stopped infusion, a determination that the 
device is in a configurable mode, elapsed time, a specific date 

25 and time, creation of the new drug library, a download of a new 
or modified drug library to the medication management unit, and 
a determination that the existing drug library at the medical 
device needs updating. The configurable mode could be any number 
of device modes including a power-on sleeping mode and a power-off 

30 mode. The determination that a trigger event has occurred can be 
made by (at) the MMU 12, the medical device 14 or by a combination 
of the two. 
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The Download Drug Library 132 then proceeds to block 250 where 
it deletes the existing drug library in primary memory 126 and 
installs the new drug library, and the new drug library from cache 
memory 126A will replace the older information in the memory 126 
5 of the medical device 14. The Download Drug Library 132 process 
is then complete and ends in block 252. 

Additional related features of the Download Drug Library 44 
program in the MMU 12 and the corresponding Download Drug Library 
132 program include recording the history of the download, verify 

10 the correct download, notification to the caregiver of a change 
of library, and a preliminary note on the medical device 14 display 
stating that the drug library will be changed after any current 
infusion (i.e., before the next infusion). 

Additionally, partial updates of the drug database within the 

15 medical device 14 are also made possible by the present invention. 
The MMU 12 is supplied with a drug database that allows a user to 
update a single data item (row, column, or cell) in the database 
without re-writing the entire database. This provides faster 
processing and downloading times when modifying the drug database. 

20 Further, the Download Drug Library 4 4 program in the MMU 12 

is designed to modify a medication library from the HIS 18 in such 
a way that only a single configuration of a single drug library 
is necessary to provide download information to multiple separate 
and different medical devices 14 where each device has unique 

25 parameters (different models, processors, computer architecture, 
software, binary format, or manufacturers, for example) . In this 
embodiment, the configured drug library is designed so that only 
a subset of the configured drug library is specific for each unique 
type of medical device 14, and only the specific information is 

30 selected for transfer to each medical device 14. Additionally, 
pre-validation of the configured drug library is done through use 
of a rule set editor prior to sending from the MMU 12 to the medical 
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device 14, and post-validation occurs where the medical device 14 
confirms receipt of an acceptable drug library back to the MMU 12. 
Further details on these additional related features can be found 
in commonly owned co-pending application entitled SYSTEM FOR 
5 MAINTAINING DRUG INFORMATION AND COMMUNICATING WITH MEDICATION 
DELIVERY DEVICES filed on February 20, 2004 , which is expressly 
incorporated herein in its entirety. 

With reference to FIGS. 2, 3, and 4A, the Monitor Pump 44 
program in the MMU 12 and the corresponding Monitor Pump 130 program 

10 in the medical device 14 operate to map the approximate or general 
physical location of each medical device 14 within the hospital 
environment and to enable a user to trigger a locator alarm to 
locate a particular medical device 14. Additionally, the 
programming enabling the medical device locator would be located 

15 in an asset manager 64 portion of the MMU 12. 

With reference to FIG. 17, the MMU 12 communicates with one 
or more (more preferably a plurality of) medical devices 14A, 14B, 
and 14C through the electronic network 76. The medical device or 
devices 14A, 14B, and 14C connect to the electronic network 76 

20 through one or more (more preferably a plurality of) access nodes 
84A, 84B, and 84C distributed in one or more (more preferably a 
plurality of) CCAs 253A and 253B. More than one medical device 
14 can operate from an individual access node 84 and be associated 
with a particular patient. Typically, there is one access node 

25 per room (101, 103, and 301), but it also is possible to have more 
than one access node per room and more than one room or CCA per 
access node. Additionally, as discussed above with regard to FIG. 
4, the connection between the medical devices 14A, 14B, and 14C 
and the access nodes 84A, 84B, and 84C can be wireless. A user 

30 access device such as a computer system 254 is remotely located 
from the MMU 12 and the medical device 14 and communicates with 
the MMU 12 to permit a user 256 to activate the Monitor Pump 44 
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program in the MMU 12 and remotely activate the corresponding 
Monitor Pump 130 program in the medical device 14. The computer 
254 can be located in a variety of locations, including but not 
limited to a nurse station or a biomemdical technician area. 

5 With reference to FIG. 18, the functional steps of the Monitor 

Pump 52 program in the MMU 12 and the corresponding Monitor Pump 
130 program in the medical device 14A are shown in operation with 
the computer 254. To begin to request a physical location for a 
medical device 14, the user 256 (not shown) enters a query for the 

10 location of a medical device 14A. The computer 254 sends a request 
device location 258 message to the MMU 12. The MMU 12 in turn sends 
a request last used access node 260 message to the medical device 
14A. It is also contemplated that the Monitor Pump Program 130 
can be operated with the input device 32. 

15 The medical device 14A determines the last access node 84A-84C 

used to connect with the electronic network 76 at step 262. A report 
of the last used access node 264 is sent from the medical device 
14 to the MMU 12. The MMU 12 processes the report of the last used 
access node 264 to determine the general physical location of the 

20 device at step 266. Once the physical location of the medical 
device 14A is determined by the MMU 12, a report physical location 
268 message is sent from the MMU 12 to the computer 254. 
Additionally, the MMU 12 tracks "change of infuser access node" 
events, when a medical device 14 begins to communicate through a 

25 different network access node 84. The MMU 12 communicates the 
physical locations of medical devices 14 to the HIS 18. 

If the user 256 requires additional assistance in locating 
the particular medical device 14A, the user 256 can instruct the 
computer 254 to send a request audio location alarm 270 message 
30 to the MMU 12. The MMU 12 in turn sends an order audio locator 
alarm 272 message to the medical device 14A. The medical device 
14A then activates an audio alarm at step 274 to assist the user 
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256 in locating the medical device 14A. The audio alarm activation 
can be delayed by a predetermined time to allow the user time to 
travel to the area of the last used access node. The audio alarm 
feature is useful in allowing the user to more precisely pinpoint 
5 the location of the medical device 14. The audio alarm feature 
is particularly useful if the medical device 14 is very close to 
other medical devices or has been moved to a storage closet or other 
location where it is not readily apparent visually. 

Alternatively, the functional steps of the Monitor Pump 44 

10 program in the MMU 12 and the corresponding the Monitor Pump 130 
program shown in FIG. 18 can be performed as a series of "push" 
steps instead of a series of "pull" steps (as shown in FIG. 18) . 
In a "push" embodiment the medical device 14A periodically 
determines the last used access node and periodically reports the 

15 last used access node to the MMU 12 as a "here I am" signal. 

Likewise, the MMU 12 periodically determines the physical location 
of the medical device 14A based on the last access node 84A used 
by the medical device 14, and periodically reports the physical 
location of the medical device 14A to the user access device 254. 

20 Alternatively, the MMU 12 programming allows it to determine which 
of access nodes 84 was the last access node used by the device 14 
(step 259 indicated by a dashed line) and the MMU can report the 
general physical location of the medical device 14 to the computer 
254 without requesting a report from the medical device 14. 

25 In one embodiment described above, the association between 

medical devices 14, patient 110, drug 100, and caregiver 114 (if 
present) , is accomplished by swiping machine readable indicators 
on each of these elements of the PAN 113 (See FIG. 4) . This 
association is made in software residing the MMU 12. Alternatively, 

30 the association is made in software residing in the medical device 
14. With reference to FIG. 21, in another embodiment, the 
association between medical devices 14A, patient 110, drug 100, 
and caregiver 114, is accomplished by "auto-association". 
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Auto-association is desirable in situations where the patient's 
wrist is not readily accessible (e.g. during surgery, or a neonate 
in an incubator) . 

In the auto-association embodiment, the MMU 12 and medical 
5 device 14A are designed to establish the patient as the focus of 
the MMS 10. In this embodiment, the patient 110 is equipped with 
a machine readable indicator 112A on a wristband, toe tag, badge 
or similar article. The machine readable indicator 112A contains 
transmitter/receiver chip 278, capable of short-range 

10 transmission. The transmitter/receiver chip 278 is a low power 
RF Bluetooth™, a dedicated RF transmitter working with a PIC 
processor, or any other suitable transmitter /receiver . The 
patient 110 is fitted with the machine readable indicator 112A at 
the time of admission. The unique ID number of the particular 

15 machine readable indicator 112A is stored with an electronic 

patient record at the HIS 18 and hence MMU 12. The MMU 12 is thereby 
notified of the particular machine readable indicator 112A 
associated with the particular patient 110. Additionally, it is 
contemplated, that any other machine readable indicator used with 

20 the present invention, may also contains transmitter/receiver chip 
capable of short-range transmission. For instance, the caregiver 
machine readable indicator 116 and medication machine readable 
indicator 102 may also be equipped with a transmitter/receiver 
chip . 

25 Each medical device 14A is also equipped with a 

transmitter/receiver chip 280A. Upon placing a medical device 14 
at the patient 110 bedside, within the PAN 113, the 
transmitter/receiver chip 280A of the medical device 14A "pings" 
by sending out a "request for patient" command to any 

30 transmitter/receiver chip 278 that is in the area. Each 

transmitter/receiver chip 278, which is in the area (usually about 
0-10 meters, more preferably about 0-3 meters) , replies to the ping 
by sending the transmitter/receiver chip 280 of the medical device 

35 



Attorney Docket No. 7135US03 



14A the unique ID number of the particular machine readable 
indicator 112A. Upon receipt of a signal from the machine readable 
indicator 112A, the medical device 14A places the ID number of the 
machine readable indicator 112A in memory 126 (See FIG. 4A) and 
5 also transmits the same to the MMU 12. Alternatively, the unique 
ID of the indicator 112A can be transmitted directly to an MMU 12 
located in the area or indirectly through another route, including 
but not limited to the medical device 14. With reference to FIGS. 
5, 5A, 6 and 6A, the MMU 12 Process Drug Order 46 program then checks 

10 the patient ID entered at step 162 and the device/channel ID entered 
at step 160 to ensure the correct match. The MMU 12 associates 
the medical device 14A only to the identified patient based on the 
patient ID number sent to the MMU 12. Dissociating the medical 
device 14A from the patient is done based on a command from a user, 

15 or other method. 

It should be noted, that the machine readable indicator 112A 
(as well as the machine readable indicator 112), can include 
equipment for monitoring the wearer, and transmitting this 
monitored information to the medical device 14 and/or the MMU 12. 

20 With reference back to FIG. 21, placing a second medical 

device 14B within the PAN 113 leads to a repeat of the same process. 
In this case the first medical device 14A "pings" any 
transmitter/receiver chip that is in the area. The 
transmitter/receiver chip 280B of the second medical device 14B 

25 replies to the ping by sending the transmitter /receiver chip 280A 
of the first medical device 14A the unique ID number of the 
particular machine readable indicator 92B. Upon receipt of a 
signal from the machine readable indicator 92B, the first medical 
device 14A places the ID number of the machine readable indicator 

30 92B in memory 126 (See FIG. 4A) and also transmits the same to the 
MMU 12. The patient ID number is then sent from the first medical 
device 14A to the second medical device 14B. 
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An additional or alternative validation of the "right 
patient" can be accomplished by caregiver visual confirmation of 
the patient following the auto-association procedure described 
above in relation to FIG. 21, and is also applicable to the 
5 five-rights procedures described above with respect to FIGS. 5, 
5A, 6 and 6A. In this process, the patient 110 is photographed 
with a digital camera (not shown) at the time of admission and the 
digital photo is stored with the electronic patient record at the 
HIS 18. When a medication order is requested for a specific patient, 

10 the digital photo is sent to the MMU 12 and upon completion of the 
association process, the digital photo is transmitted from MMU 12 
to the medical device 14 at the patient 110 bedside. The image 
of the patient 110 is sent to the display 88 of the medical device 
14, which is preferably a high resolution touch screen at least 

15 approximately 12 cm by 12 cm. The image of the patient 110 is then 
placed on the display 88 and the caregiver 114 is prompted by the 
display 88 to "Confirm Patient". The caregiver 114 confirms a 
patient match upon visual comparison of the patient 110 with the 
image on the display 88. 

20 Alternatively, the digital photo information alternatively 

can be stored on the indicator 112 or 112A and transmitted by the 
transmitter/receiver 178 thereof. The digital photo is 
transmitted to the medical device 14 when the medical device 14 
has been associated with the patient 110. 

25 With reference to FIG., 22, another portion of the functional 

steps of the Monitor Pump 52 program in the MMU 12 and the 
corresponding Monitor Pump 130 program in the medical device 14 
are shown in operation with the computer 254. To begin to request 
a specific evaluation for the operation of a specific medical 

30 device 14, or group of medical devices 14, the user 256 (not shown) 
enters a query for the operation evaluation of a medical device 
14. The computer 254 sends an operation evaluation request 282 
message to the MMU 12. The MMU 12 in turn sends a request operation 
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data 284 message to the medical device 14. The medical device 14 
sends a report operation data 286 message (including but not 
limited to event logs, settings, CCA and utilization information) 
back to the MMU 12 at step 28 6. The MMU 12 processes the report 
5 operation data 286 to generate an operational evaluation at step 
288. Once the operational evaluation of the medical device 14 is 
determined by the MMU 12, a report operational evaluation 290 
message is sent from the MMU 12 to the computer 254. 

Alternatively, the functional steps of the Monitor Pump 44 

10 program in the MMU 12 and the corresponding the Monitor Pump 130 
program shown in FIG. 22 can be performed as a series of "push" 
steps instead of a series of "pull" steps (as shown in FIG. 22) . 
In a "push" embodiment the medical device 14 periodically reports 
the operation data to the MMU 12. Likewise, the MMU 12 periodically 

15 processes the report operation data 286 to generate an operational 
evaluation at step 288, and periodically reports the operational 
evaluation of the medical device 14 to the user access device 254 
at step 290. 

The automated operational evaluation described above, 
20 provides a method of evaluating medical device 14 while in 

operation; thus eliminating the need to postpone evaluation until 
the medical device 14 is taken out of use. The real-time data 
collection capabilities of the MMU 12 and Monitor Pump 52 program 
allow the MMU 12 to determine medical device 14 performance 
25 including advanced statistical operations in order to provide 

quality control data sorting algorithms and aggregation of data 
and control for a PAN 113 (not shown) . For example, consider a 
MMS 10 where multiple discreet single or multiple channel medical 
devices 14 (or channels) are connected to a single patient 110 (not 
30 shown) . The Monitor Pump 52 program collects all medical device 
14 information in real-time and then compares medical device 14 
statistics to one another. Likewise, infuser channels can be 
compared to other infuser channels within the same multiple channel 

38 



Attorney Docket No. 7135US03 



medical device or in other devices. Monitor Pump 52 program 
therefore can detect a "bad actor" if any one of the medical devices 
14 or channels is operating at a level statistically lower or higher 
than the other medical devices 14 or channels. This statistical 
5 determination can be made by collecting and comparing the mean and 
standard deviation of appropriate data elements. This statistical 
determination can be performed selectably on any of the data that 
is routinely collected by the medical device 14 event log and any 
that may be acquired from the instrumentation of the medical device 

10 14. For example, statistical determinations could be performed 
based on air alarm events, occlusion alarm events, battery usage 
data, screen response time, etc. MMU 12 then sends the operational 
evaluation message (including any relevant quality control alert) 
to an appropriate area (including but not limited to the computer 

15 254) in a form that is appropriate for the particular alert (usually 
including but not limited to graphically or audibly) . Additionally, 
operational evaluation message (including any relevant quality 
control alert) can be sent to any number of individuals including 
but not limited to the caregiver, a biomedical engineer, caregiver 

20 supervisor, and a doctor. 

With reference to FIG. 17, the medical device 14 is designed 
as a multi-processor, where many features are not hardwired, but 
instead can be uniquely configured based on rules, the location 
of the medical device 14, etc. For example, the medical device 

25 14 is designed to allow a customized display based on the Clinical 
Care Area (CCA) 253A or 253B the medical device 14 is located in 
and/or assigned too. An example of this would be the MMU 12 
instructing the medical device 14 to have a display of a particular 
color or warning tones/volumes based on the location of the medical 

30 device 14 in the hospital, time of day, caregiver information, 
patient information, or the type of medication being supplied. For 
example, the patient information could include a patient diagnosis 
and/or a disease state. For example, alarm volumes and display 
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brightness can be set lower in the pediatric clinical care area 
or at night than in the emergency room clinical care area or during 
the daytime. 

With reference to FIG. 4, similarly, the medical device 14 
5 is designed to allow a customized display based on user information 
supplied to the medical device 14 (from the MMU 12 for example) . 
Such user based customized display could include changes in 
language preference, limited access depending on the security 
level of the caregiver 114 , customizing the displayed information 

10 based on the training level of the individual or recent 

interactions therewith, and/or customizing an automated help 
function based on training level of the user or recent interactions 
therewith. The MMU 12 presents a user with a default view based 
on the user's role. The MMU 12 permits a default view for each 

15 role to be configurable in terms of the data detail presented. The 
MMU 12 allows a user with the appropriate privilege to set a 
particular presented view as the preferred or default starting view 
for that user following login. The MMU 12 allows a user to access 
databases and details based on role and privilege. The MMU 12 

20 allows a user to access other views based on role and privilege. 
Each presented view includes: a common means of navigating among 
views, both summary and detail, access to privacy, security, and 
other policy statements, access to online help, and a logoff 
capability. Additionally, an emergency bypass (such as a 

25 pass-code) would be provided to bypass security restrictions in 
case of an emergency. 

With reference to FIG. 22, another portion of the functional 
steps of the Monitor Pump 52 program in the MMU 12 and the 
corresponding Monitor Pump 130 program in the medical device 14 
30 are shown in operation with the computer 254. The MMU 12 tracks 
and records actions taken by the caregiver 114 based on operational 
data reported from one or more medical devices 14. Just as the 
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MMU 12 is capable of generating an operational evaluation of each 
medical device 14 , the MMU 12 can likewise generating an 
operational evaluation of each caregiver 114 (not shown) at step 
288. This operational evaluation of each caregiver 114 includes 
5 records of each caregiver's 114 actions (or, in some cases, 

inactions) , sorting of these actions based on given criteria, and 
tracking of any trends in these actions. In general, these records 
of actions include any task lists, medication administration 
records, treatments, and other actions associated with the 

10 caregiver's 114 responsibilities. Such records of actions may 
combine medications administered, treatments, and other actions 
for multiple patients under the care of an individual caregiver. 
MMU 12 then sends the operational evaluation message (including 
any relevant quality control alert) to an appropriate area (e.g. 

15 to the computer 254 or caregiver supervisor's computer (not shown) ) 
in a form that is appropriate for the particular alert (usually 
including but not limited to graphically or audibly) . Additionally, 
operational evaluation message (including any relevant quality 
control alert) can be sent to any number of individuals including 

20 but not limited to the caregiver, a biomedical engineer, caregiver 
supervisor, and a doctor. 

Additionally, the MMU 12 can instruct the medical device 14 
to customized display 88 based on the operational evaluation 
message. Thus, the display 88 is adjusted by the MMU 12 based a 

25 determination that the caregiver 114 requires additional or 
different information displayed to improve caregiver 114 
interaction with the medical device 14. For example, detailed step 
by step instructions can be placed on display 88, where the MMU 
12 recognizes a caregiver 114 who is not familiar with a particular 

30 therapy, using the display 88 as the instruction means. Likewise, 
where the MMU 12 recognizes that a caregiver 114 has limited 
experience programming the medical device 14 (caregiver 
experience) or in previous interactions had made errors 
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programming a particular function (caregiver error rate) or was 
a statistically longer than the norm at programming a particular 
function (caregiver response time) , the MMU 12 instructs the 
medical device 14 to display pertinent training information. 
5 In another embodiment best understood with reference to FIG. 

4A, the medical device 14 is designed to act as a web server for 
the input device 32 or other similar devices within proximity to 
the medical device 14. In this embodiment, medical device 14 is 
equipped to supply the input device 32 web browser with medical 

10 device related information as well as non-medical device related 
information such as task lists, etc. Additionally, the medical 
device 14 displays a dual function screen having both a pump monitor 
screen portion and a web browser screen portion. Further, 
supplying the medical device 14 as a web server permits a remote 

15 web browser to associate with the medical device 14 to configure 
the medical device 14 or run diagnostics on the medical device 14. 

With reference to FIGS. 2 and 4A, another portion of the 
Monitor Pump 52 program in the MMU 12 and the corresponding Monitor 
Pump 130 program in the medical device 14 is directed to cloning 

20 between medical devices 14. The medical devices 14 are designed 
to have wireless data sharing between each medical device 14 
sufficient to permit cloning of all patient information between 
each medical device 14, and/or the multi-sequencing of a set of 
medical devices 14 without a hardwired connection. The MMU 12 

25 adjudicates this cloning and/or multi-sequencing. 

Whereas the invention has been shown and described in 
connection with the embodiments thereof, it will be understood that 
many modifications, substitutions, and additions may be made which 
are within the intended broad scope of the following claims. From 

30 the foregoing, it can be seen that the present invention 
accomplishes at least all of the stated objectives. 
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